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FOREWORD 


Among  the  responsibilities  assigned  to  the  Office  of  the  Manager,  National 
Communications  System,  is  the  management'  of  the  Federal  Telecommunication 
Standards  Program  which  is  an  element  of  the  overall  GSA  Federal  Standardiza¬ 
tion  Program.  Under  this  program,  the  NCS,  with  the  assistance  of  the  Federal 
Telecommunication  Standards  Committee,  identifies,  develops,  and  coordinates 
proposed  Federal  Standards  which  either  contribute  to  the  interoperability  of 
functionally  similar  Federal  telecommunication  systems  or  to  the  achievement 
of  a  compatible  and  efficient  interface  between  computer  and  telecommunication 
systems.  In  developing  and  coordinating  these  standards  a  considerable  amount 
of  effort  is  expended  in  initiating  and  pursuing  joint  standards  development 
efforts  with  appropriate  technical  committees  of  the  Electronic  Industries 
Association,  the  American  National  Standards  Institute,  the  International 
Organization  for  Standardization,  and  the  International  Telegraph  and  Tele¬ 
phone  Consultative  Committee  of  the  International  Telecommunication  Union. 

This  Technical  Information  Bulletin  (TIB),  one  of  a  series,  is  a  companion 
document  to  NCS  TIB  80-7  (which  incorporates  all  substantive  material 
contained  in  NCS  TIB  80-2),  and  has  been  prepared  to  inform  interested  Federal 
activities  of  the  progress  of  these  efforts.  Any  comments,  inputs,  or  state¬ 
ments  of  requirements  which  could  assist  in  the  advancement  of  this  work  are 
welcome  and  should  be  addressed  to: 


Office  of  the  Manager 
National  Communications  System 
ATTN:  NCS-TS 

Washington,  D.C.  20303 
(202)  692-2124 
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1.0  INTRODUCTION 


This  document  summarizes  the  work  performed  by  Delta 
Information  Systems,  Inc.  for  the  Office  of  Technology  and 
Standards  of  the  National  Communications  System,  an  organi¬ 
zation  of  the  U.  S.  Government,  under  Purchase  Order 
DCA100-80-M-0221 .  The  Office  of  Technology  and  Standards, 
headed  by  National  Communications  System  Assistant  Manager 
Marshall  L.  Cain,  is  responsible  for  the  management  of  the 
Federal  Telecommunications  Standards  Program,  which  develops 
telecommunication  standards  whose  use  is  mandatory  by  all 
Federal  agencies.  The  objective  of  this  program  is  to  develop 
a  block  diagram,  flow  charts,  and  computer  programming 
for  the  Reject  and  Selective  Reject  functions  of  the  unbalanced 
normal,  unbalanced  asynchronous,  and  balanced  asynchronous 
class  of  procedures  in  accordance  with  Federal  Standard  1003. 
The  purpose  of  this  effort  is  to  determine  the  feasibility 
of  using  the  M6800  or  similar  microprocessor  to  implement 
this  type  of  protocol,  and  to  obtain  an  estimate  of  memory 
and  processor  resources  that  would  be  required.  The  Office 
of  Technology  and  Standards  will  use  the  information  to 
advise  other  Federal  agencies  who  implement  the  standard 
and,  when  merged  with  the  results  of  other  studies,  to  evaluate 
the  operational  and  economic  impact  of  incorporating  various 
options  in  Federal  Standard  1003. 

The  effort  necessarily  has  focussed  on  the  software 
required  to  implement  the  protocol  itself  ,  and  is  by  no 
means  a  total  hardware/software  system  design  that  would  be 
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required  to  develop  a  complete  system.  Complete  system 
development  is,  of  course,  beyond  the  scope  of  this  program. 

A  discussion  of  the  method  of  implementation  of 
Reject  and  Selective  Reject  is  included  in  Section  2.  Flow 
charts  describing  the  software  that  makes  up  the  protocol 
included  in  Section  4.  These  flow  charts  describe  the  pro¬ 
tocol  software  processes  in  sufficient  detail  that  code  may 
be  written  with  no  major  design  decisions.  The  flow  charts 
at  this  level  are  very  hardware  dependent. 

A  small  portion  of  the  code  for  the  6800  microprocessor 
has  been  written  and  is  included  in  Section  5.0.  The  code 
was  intorduced  into  a  6800  microcomputer,  provided  by  Delta 
Information  Systems.  The  code  in  the  computer  was  then  tested 
to  insure  its  validity.  Finally  Section  6.0  contains  a  dis¬ 
cussion  of  the  feasibility  of  using  the  6800  to  implement  the 
ADCCP  protocol.  It  is  estimated  that  approximately  1300 
instructions  are  needed  to  implement  the  three  classes  of 
procedures  in  a  logically  configurable  station  (primary, 
secondary,  or  combined)  with  the  Selective  Reject  option 
(1200  instructions  with  the  Reject  option) ,  and  that  approx¬ 
imately  250  instructions  are  required  for  the  operating 
system.  Data  transmission  rates  of  up  to  19.2  kilibit/sec. 
appear  feasible  for  the  configuration  being  considered. 


2.0  SYSTEM  DESIGN  CONSIDERATIONS 


The  block  diagram  in  Figure  2-1  shows  a  link  with  one 
primary/combined  and  one  secondary/combined  station  communicating 
with  each  other  by  sending  information  in  both  directions.  That 
is,  either  station  may  be  a  source  or  sink  of  data  or  both. 
Two-way  simultaneous  transmission  is  assumed.  Although  many 
secondary  stations  may  communicate  with  one  primary  station, 
the  objectives  of  this  program  can  be  met  with  no  loss  of 
generality,  by  assuming  the  existence  of  only  one  secondary 
station . 

Each  station,  primary,  secondary,  or  combined  is  made 
up  of  a  microcomputer,  an  LSI  interface  to  the  link,  and  a 
user  which  supplies  and  uses  the  data  to  be  communicated.  The 
primary  and  secondary  stations  are  physcially  very  similar; 

operationally,  of  course,  the  primary  must  supervise  and  control 
a  number  of  secondary  stations,  and  thus  it  requires  a  larger 
data  structure  and  somewhat  more  complicated  code. 

For  the  purpose  of  this  program,  the  microcomputer 
can  be  assumed  to  be  very  basic — microprocessor,  memory  (RAM 
and  ROM),  interface  chips,  clock,  etc.  A  design  c.io.ce  that 
has  significant  impact  on  the  outcome  of  this  program  is  the 
choice  of  the  LSI  interface.  The  purpose  of  the  LSI  inter¬ 
face  is  to  convert  the  parallel  data  from  the  CPU  to  a 
continuous  serial  data  stream  for  transmission.  Simultaneously, 
it  must  convert  received  serial  data  to  parallel  data  for  the 
CPU.  In  addition,  it  must  generate  and  verify  the  frame  check 


sequence  (FCS) ,  stuff  and  delete  O's  to  distinguish  FLAG  or 
ABORT  from  data,  insert  and  detect  FLAG  or  ABORT,  and  insert 
interframe  fill  or  idle  link  fill.  Other  functions  may 
also  be  performed  by  this  interface. 

Two  different  LSI  chip  specif iciations  have  been 
examined  as  possible  candidates  for  the  interface  function 
in  this  particular  study.  These  chips,  which  represent 
different  approaches  to  the  interface  problem,  are  the  F6856 
and  the  WD2501.  (Refer  to  a  previous  report  (1)  for  a  copy 
of  their  preliminary  data  sheets  and  a  brief  comparison) . 

At  least  three  other  similar  protocol  chips  have  become 
candidates  since  the  beginning  of  this  effort.  These  are 
the  Solid  State  Scientific  SND5025,  the  Signetic  2652  and 
the  Zilog  SIO. 

The  F6856  chip  was  selected  for  this  program  by  mutual 
consent  of  the  contractor  and  the  government.  The  interface 
to  the  communications  lines  requires  additional  logic  such 
as  a  Federal  Standard  1031  (Electronic  Industries  Association 
Recommended  Standard  449)  interface  chip  and  a  modem,  but 
the  choice  of  these  has  little  impact  on  this  program. 

The  data  transmitted  over  the  link,  must  also  be 


transmitted  to  the  user.  The  interface/protocol  required 
between  the  microcomputer  and  the  user  is  also  part  of  the 
system  design.  However,  for  this  program,  the  protocol 
has  not  been  defined.  The  interface,  including  the  buffers 
to  hold  the  data,  is  defined  and  described  in  Section  4.0. 
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3.0  REJ/SREJ  IMPLEMENTATION 

The  objective  of  this  program  is  to  add  the  Reject 
(REJ)  and  the  Selective  Reject (SREJ)  functions  to  the 
design  of  the  ADCCP  according  to  the  Federal  Standard 
1003  and  to  estimate  the  memory  and  processor  resources 
that  these  functions  require.  The  REJ  and  SREJ  protocols 
may  be  used  in  a  number  of  ways:  pure  REJ,  pure  SREJ,  and 
various  combination^ ^f  these  two  including  a  look-ahead 
SREJ/REJ.  For  the  pure  REJ  protocol,  the  receiver  of 
information  frames  uses  the  REJ  supervisory  frame  to  request 
the  sender  of  information  frames  to  back  up  to  an  earlier 
point  and  begin  retransmission.  On  the  other  hand,  SREJ 
requests  a  single  previous  information  frame  followed  by 
the  continuation  of  the  send  sequence.  REJ  and  SREJ  may  be 
used  together  in  various  combinations  depending  on  whether 
the  lost  frame  is  single  or  multiple  and  if  an  exception 
condition  exists  when  a  new  loss  is  detected. 

The  addition  of  REJ  and  SREJ  to  the  ADCCP  protocol  also 
adds  some  complexity  (especially  for  SREJ) .  This  is  due 
to  the  somewhat  redundant  nature  of  the  reject  protocols  with 
respect  to  the  checkpointing  and  timeout  mechanisms.  Although 
the  reject  mechanism  is  more  efficient,  checkpointing  must 
be  operational  as  a  backup  in  case  the  REJ  or  SREJ  frames 
or  the  retransmitted  information  frames  are  lost  due  to  errors. 
Care  must  be  taken  to  ensure  that  the  checkpointing  mechanism 
works  with  the  reject  frames  while  preventing  redundant 
retransmission. 
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Only  the  pure  REJ  and  pure  SREJ  have  been  included  in 


the  design,  because  these  are  adequate  to  allow  memory 
requirements  and  speed  to  be  estimated.  However,  the  software 
design  has  been  reorganized  to  provide  for  pure  REJ,  pure  SREJ, 
or  a  combination  of  these  options  for  error  recovery.  This 
has  been  accomplished  by  the  inclusion  of  a  recovery  module 
in  the  subroutine  that  receives  information  frames.  As 
described  in  more  detail  farther  along  in  the  report,  this 
module  is  programmed  for  the  desired  recovery  option.  If  a 
more  complex  recovery  option  is  desired  such  as  a  look-ahead 
REJ/SREJ  option,  most  of  the  software  for  this  option  will 
reside  in  the  recovery  module  and  the  other  modules  will 
suffer  little  change. 


* 
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4.0 


DETAILED  SOFTWARE  DESIGN 


In  this  section  the  software  design  is  presented  in 
sufficient  detail  to  allow  the  objectives  of  this  program  to 
be  met:  that  is,  the  feasibility  of  using  the  6800  and 
an  estimate  of  memory  and  throughput  can  be  obtianed.  The 
design  covers  the  major  aspects  of  a  logically  configurable 
station;  functions  that  allow  the  station  to  operate  as  a 
primary,  secondary,  a  combined  station  in  unbalanced  normal, 
unbalanced  asynchronous  or  balanced  modes  are  included. 

Operation  as  a  secondary/combined  station  is  emphasized, 
since  FED-STD-1003  does  not  cover  many  of  the  primary/ 
combined  station  procedures  for  managing  the  link.  These 
are  left  to  the  system  designer.  The  software  design  includes 
a  description  of  a  minimal  operating  system  to  handle  concur¬ 
rent  processes,  major  data  structures,  major  software  routines, 
and  a  set  of  detailed  flow  charts. 

The  detailed  flow  chart,  together  with  associated  data 
structures,  describes  the  protocol  software  processes  in 
sufficient  detail  so  that  code  may  be  generated  with  no  major 
design  decisions.  The  flow  chart  at  this  level  is  hardware 
dependent,  and  must  take  into  consideration  the  time  constraints 
imposed  by  the  concurrent  software  processes  associated  with 
the  implementation  of  the  protocol. 

The  protocol  is  made  up  of  four  major  concurrent  software 
processes,  each  of  which  is  an  example  of  the  classic  producer/ 
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consumer  problem.  In  this  problem,  one  process  produces 
items  and  then  deposits  them  into  a  buffer.  A  second  process 
consumes  the  items  by  taking  them  from  the  buffer.  The 
processes  must  be  coordinated  so  that  the  consumer  does 
not  run  ahead  of  the  producer,  and  that  the  producer  does 
not  write  over  records  before  the  consumer  has  had  a  chance 
to  read  them.  For  the  protocol  problem,  two  concurrent  pro¬ 
cesses  are  involved  in  communicating  data  between  the  LSI 
interface  and  the  microprocessor;  the  LSI  chip  deposits  bytes 
in  its  buffer  as  the  producer,  and  the  MPU  reads  this  data 
as  the  consumer.  Conversely,  the  microprocessor  writes  data 
into  a  buffer  as  the  producer,  to  be  read  by  the  LSI  chip  as 
the  consumer  and  transmitted  over  the  link.  A  similar  pair 
of  processes  serves  to  implement  the  interface  between  the 
microprocessor  and  the  higher  level  user.  For  this  effort, 
emphasis  is  placed  on  the  interface  between  the  MPU  and  the 
LSI  protocol  chip.  This  requires  two  main  processes  to  be 
running  at  the  same  time — transmit  and  receive.  The  operating 
system  that  manages  these  processes  is  presented  in  Appendix 
A. 

The  purpose  of  this  phase  of  the  program  is  to  add  the 
REJ  and  SREJ  functions  to  the  design  and  estimate  the  memory 
and  processor  resources  that  these  functions  require.  In 
order  to  accommodate  REJ  and  SREJ  in  a  modular  fashion, 
the  routines  that  receive  I  frames  and  that  transmit  I  and 
supervisory  frames  have  been  reorganized  and  supplemented.  For 
example,  the  receive  I  subroutine  now  includes  a  recovery  module 
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that  can  be  used  for  REJECT,  or  SREJECT,  or  neither  depending 
on  which  of  three  software  routines  are  included.  Note  that 
either  pure  REJ  or  pure  SREJ  is  included  and  not  a  combination 
of  the  two.  The  combination  could  be  added  as  a  fourth  recovery 
technique,  although  for  the  purpose  of  measuring  memory  and 
processor  resources  the  pure  REJ  and  SREJ  provide  an  adequate 
vehicle.  If  neither  REJ  or  SREJ  are  employed  the  error 
recovery  defaults  to  the  checkpointing  mechanism. 

In  addition  to  the  receive  I  frame  routine,  the  process 
that  transmits  I  and  supervisory  frames  was  modified  to 
enable  REJ  and  SREJ  transmission  and  retransmission  when  appro¬ 
priate.  The  ability  to  reset  the  send  variable  as  a  result 
of  receiving  REJ  was  provided  as  well  as  the  ability  to  transmit 
a  selected  I  frame  as  a  result  of  receiving  SREJ.  Two  new 
routines  were  added  to  act  on  a  received  REJ  or  SREJ. 

4.1  DATA  STRUCTURES 

This  section  outlines  the  data  structures,  including 
variables,  arrays,  buffers,  etc.  in  order  to  more  easily 
understand  the  detailed  flow  charts  that  follow  and  to 
estimate  the  amount  of  random  access  memory  (RAM)  that  is 
required  to  implement  the  protocol.  Main  state  variables  are 
as  follows: 

STATION  TYPE  -  PRIMARY,  SECONDARY,  OR  COMBINED 

(mutually  exclusive) 

OPERATIONAL  STATE  -  has  3  values,  mutually  exclusive: 

LDS  -  Logically  disconnected  state 
ITS  -  Information  transfer  state 

FRMR  -  Frame  reject  s*-ate  (for  secondary/combined) 
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Logically  disconnected  state  has  two  mutually 
exclusive  modes: 

NDM  -  normal  disconnected  mode 
ADM  -  asynchronous  disconnected  mode 
Information  transfer  state  has  three  mutually 
exclusive  modes: 

NRM  -  normal  respond  mode 
ARM  -  asynchronous  respond  mode 
ABM  -  asynchronous  balanced  mode 
Other  major  variables  are: 

REMOTE  BUSY  -  true  if  RNR  received 

false  if  RR  received  or  P/F  bit 
set  in  received  I-frame 

STATION  BUSY  -  true  if  not  prepared  to  receive 
information;  false  otherwise 
SNDREJ /  SNDSREJ  -  flag 
REJ/SREJ  ACTIONED  -  state  variable 
SENT  REJ/SREJ  -  state  variable 
P-BIT  -  Poll  bit 
F-BIT  -  final  bit 

S  -  Send  Variable  (next  I-frame  to  be  transmitted) 
R  -  Receive  Variable  (expected  sequence  number 
of  next  received  I-frame) 

N  (S)  -  Send  Sequence  Number  (I-frame  sequence 
number ) 

N (R)  -  Receive  Sequence  Number  (station  trans¬ 
mitting  N (R)  has  correctly  received  all 
I-frames  up  to  and  including  N(R)-l) 
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Operating  System  variables  include: 

RDAI'LG  -  Receive  data  available  event  variable 
TBMT  -  Transmitter  buffer  empy  event  variable 


Pointers  to  beginning  of  each  queue 


RUNNING 
BLOCK 
READY 

PCB  -  Each  process  control  block  contains: 
condition  code  register 
accumulator  A 
accumulator  B 

index  register  (upper  and  lower) 
program  counter  (upper  and  lower) 
pointer  to  next  PCB 
priority 

A  number  of  buffers  are  required  for  such  things  as  the  received 
control  word,  transmitted  control  word,  frame  type, etc.  Next, 
consider  the  data  buffer  required  to  transmit/receive  information 
between  CPU  and  USER.  Assume  that  a  separate  buffer  is  required 
for  tansmit  and  receive,  and  that  each  buffer  can  hold  up  to 
eight  I-frames  of  data.  These  buffers  are  accessed  via 
tables  shown  in  Figure  4-6.  Each  frame  to  be  transmitted 
via  the  LSI  chip  has  a  starting  address  for  the  data  and  length 
in  bytes  of  the  data  part  of  the  frame.  If  the  frame  was 
transmitted  with  the  poll/final  bit  set,  this  is  recorded. 

The  "acknoweldge"  variable  is  used  to  indicate  whether  a  frame 
has  been  deposited  by  the  USER  for  transmission,  whether  it 
has  been  transmitted,  and  finally,  whether  it  has  been 
acknowledged  by  the  receiving  station.  In  the  example  shown. 
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six  frames  have  been  deposited  by  the  USER  for  transmission, 
three  have  been  transmitted  ending  with  a  final  bit  (SECONDARY- 
NRM) ,  and  the  first  frame  has  been  acknowledged.  Three 
frames  remain  to  be  transmitted.  The  received  look-up 
table  performs  a  similar  function  for  data  received  from  the 
LSI  chip.  Each  frame  is  assembled  byte-by-byte  and  the 
frame  length  is  incremented.  When  the  frame  has  been  correctly 
received  (valid  FCS  and  N(S))  the  frame  is  tagged  as  verified 
and  may  be  read  by  the  user. 

The  buffers  and  associated  variables  required  for  LSI 
Interface  chip  operation  are  shown  in  Figures  4-2,  4-3,  and 
4-4.  The  Mode  Control  Register  (MCR)  contains  control  infor¬ 
mation  common  to  both  receiver  and  transmitter.  The  SAR 
contains  the  secondary  station  address.  The  TCR  is  loaded  by 
the  MPU  to  control  the  transmitter,  and  the  TDB  contains  the 
byte  to  be  transmitted.  The  Receiver  Status  Register  (RSR) 
is  read  by  the  MZU  to  determine  the  status  of  the  byte  received 
in  the  Received  Data  Buffer  (RDB) .  The  RCR  contains  control 
information  for  the  receiver  and  the  TSR  supplies  transmitter 
status.  Refer  to  previous  report  for  a  detailed  description 
of  receiver/transmitter  operation  and  flow  charts  for  the 
F6856  LSI  interface  chipe 
4.2  SUBROUTINE /FUNCTION  DESCRIPTIONS 

This  section  describes  the  functions  of  software 
modules  that  make  up  the  protocol.  Figure  4-5  contains  a 
table  of  all  the  significant  software  modules  organized  by 
station  types  (primary,  secondary,  or  common  to  both)  and 
by  whether  the  module  is  associated  primiarly  with  a  transmit 
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Figure  4-5  Software  Modules 
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or  receive  process.  Those  modules  contained  in  the  operating 
system  have  been  discussed  previously.  Some  of  the  modules 
are  the  main  routines  for  processes,  namely  INIT,  RCV,  SENDI , 
and  IDLE.  INIT  is  the  intialization  process,  RCV,  is  the 
process  that  receives  and  processes  the  address  and  control 
bytes  of  the  received  frame,  SENDI  is  the  main  transmitting 
process,  and  IDLE  is  a  simple  process  that  runs  when  all 
other  processes  are  blocked.  DUMMY  is  a  process  that  is 
never  run,  but  serves  as  a  place  for  the  IDLE  process  to 
point  to  and  has  the  lowest  priority.  Those  modules  that 
are  associated  only  with  either  the  primary/combined  or 
secondary/combined  stations  are  mostly  mode-setting  or 
mode  acknowledging  functions  and  are  relatively  simple. 

GETBYT  is  a  macro  that  reads  the  receive  buffer  if 
data  is  available  and  stores  the  data  in  a  location  specified 
in  the  macro  agreement.  Interrupts  are  disabled  for  the 
duration  of  the  macro  to  prevent  flags  or  data  from  changing 
while  reading.  If  no  data  is  available,  the  process  is 
blocked  via  WAIT.  The  SNDBYT  macro  loads  the  transmitter 
buffer  with  operation  similar  to  that  in  GETBYT. 

FRMREJ  changes  the  state  of  the  secondary/combined 
station  to  frame  reject,  assembles  the  FRMR  information 
field,  and  activates  the  FRMR  transmit  process  called  TR-FRMR. 
This  process  terminates  any  other  transmit  process  except 
TR-DM,  or  TR-UA,  sends  the  FRMR  frame,  and  then  terminates 
itself.  The  FRMR  routine  receives  a  FRMR  frame  (implies  a 
primary/combined  station)  and  takes  appropriate  mode  setting 
action. 


i 
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SENDI  process  -  Transmits  I  and  all  supervisory  frames 

REFERENCES:  P/F  received 

Information  transfer  mode 
SENT  SREJ  state  variable 
P/F  PREVIOUS  State  variable 
STATION  BUSY  state  variable 
REMOTE  BUSY  state  variable 
SREJ  ACTIONED  state  variable 

MODIFIES:  SNDSREJ  flag 

SENDRJ  return 
S  -  send  variable 
TIME  OUT 

CALLS :  SENDRJ 

SNDRR 
SNDRNR 

EXIT:  NONE 

FUNCTION:  The  function  of  the  SENDI  process  is  to  transmit 

I  frames  and  to  transmit  supervisory  frames  as 
required.  The  process  begins  with  a  determination 
of  whether  or  not  to  retransmit  a  previously 
transmitted  SREJECT.  If  not,  a  REJECT  or  SREJECT 
may  be  transmitted  depending  on  the  SNDREJ /SNDSREJ 
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flag.  Then,  ; f  data  is  available  foe  trans¬ 
mission  and  the  remote  station  is  not  busy,  the 
loop  for  transmitting  I  frames  is  entered  at 
NEXTI .  If  SREJ  has  been  actioned,  the  requested 
frame  is  set  up  for  retransmission.  Next,  if 
P  and  NRM  the  F  bit  is  set.  SREJ  is  retransmitted 
as  required.  Next  the  complete  I  frame  is  trans¬ 
mitted  byte  by  byte  and  the  send  variable  (S)  is 
incremented.  If  the  remote  station  is  found  to 
be  busy  RR  or  RNR  is  transmitted  as  appropriate. 

If  more  frames  are  available  for  tansmission 
the  loop  is  repeated  from  NEXTI.  If  not, 
the  process  is  repeated  from  SENDI . 
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SNDRR  Subroutine  -  Sends  Receive  Ready 


REFERENCES:  P/F  received 

Information  transfer  mode 

SENTSREJ  state  variable 
P/F  PREVIOUS  state  variable 
STATION  BUSY  state  variable 
R  -  receive  variable 

MODIFIES:  SNDSREJ  state  variable 

TIMEOUT 

CALLS :  SENDRJ 

EXIT:  NORMAL  RETURN 

FUNCITON:  This  routine  is  used  to  send  Receive  Ready  and 

also  to  send  SREJECT  if  appropriate.  First,  a 

decision  is  made  whether  or  not  to  retransmit 
a  previously  sent  SREJ.  If  not,  the  SENDRJ 
subroutine  is  called  to  send  REJ  or  SREJ  depending 
on  the  SNDREJ  and  SNDSREJ  flags  and  the  STATION 
BUSY  state  variable.  Finally,  RECEIVE  READY  is 
transmitted  {or  not)  depending  on  the  P/F  bit 
and  the  information  transfer  state. 


SNDRNR  Subroutine  -  Sends  Receive  Not  Ready 


REFERENCES:  P/F  received 

Information  transfer  mode 
R  -  receive  variable 

MODIFIES:  TIMEOUT 

EXIT:  NORMAL  RETURN 


FUNCTION:  This  routine  sends  Receive  Not  Ready  depending 

on  the  P/F  bit  and  the  information  transfer 
state.  Functionally  it  is  similar  to  SNDRR , 
except  that  there  is  no  provision  to  send 
SREJ  because  RNR  Implies  that  the  station  is 
busy . 


SENDRJ  Subroutine 


Transmit  REJECT  or  SREJECT  routine 


REFERENCES:  STATION  BUSY  state  variable 

SNDREJ/SNDSREJ  flag 
R  -  receive  variable 

MODIFIES:  SNDREJ/SNDSREJ  flag 

Timeout 

EXIT:  NORMAL  RETURN 

FUNCTION:  After  determining  that  STATION  BUSY  is  false 

and  that  either  SNDREJ  or  SNDSREJ  is  true,  a 
supervisory  command/response  of  REJ  or  SREJ  i 
transmitted,  as  appropriate.  The  SNDREJ/ 
SNDSREJ  flag  is  set  false  before  returning. 


I  Module 


Receive  1  frame  routine 


REFERENCES : 


MODIFIES: 


EXIT: 


FUNCTION: 


OPERATIONAL  STATE  Varaible 

FRMR  -  frame  reject  state  variable 

LENGTH  -  number  of  bytes  in  information  field 

P/F  received 

N  ( S )  received 

R  -  receive  variable 

REJ/SREJ  SENT  state  variable 

LENGTH 

R 

REJ/SREJ  SENT 
SNDREJ/SNDSREJ  flag 

RCV 

FRMRI 

This  routine  is  used  to  make  the  appropriate 
checks  on  the  I-frame  control  field  and  to 
read  the  information  field  byte-by-byte.  First, 
a  check  is  made  to  ensure  that  the  receiver  is 
either  in  information  transfer  state  (ITS)  or 
frame  reject  state  (FRMR) .  If  so,  the  information 
field  is  read  in  a  byte  at  a  time.  Next,  tests 
are  made  for  a  good  frame  check  sequence  (FCS)  , 
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no  FRMR,  and  an  I-frame  information  field  of  the 
correct  length.  If  all  of  these  tests  pass, 
the  send  sequence  number  ( N  ( S ) )  received  is 
compared  with  the  receive  variable  (R)  and 
appropriate  action  taken  depending  on  whether 
or  not  there  is  an  error  and  on  the  method 
of  error  recovery.  One  of  the  three  methods 
of  error  recovery  that  are  presented  may  be 
used  at  a  given  time.  These  include  REJECT 
recovery,  SREJECT  recovery,  and  checkpoint 
recovery . 

SREJECT  recovery  is  used  to  request  that  a 
specific  frame  be  retransmitted.  Following 
frames  are  buffered  until  the  requested  frame 
is  received  and  then  the  receive  variable  is 
advanced  accordingly.  REJECT  is  similar  except 
that  all  frames  following  the  frame  in  error 
must  be  retransmitted.  If  neither  REJECT 
nor  SREJECT  is  employed,  the  checkpointing 
mechanism  must  be  relied  on  to  perform  error 
recovery:  thereceiver  simply  ignores  the  frame, 

and  the  transmitter  must  discover  the  error 
via  N(R)  and  the  P-F  checkpoint  cycle. 
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RR/RNR  Module  -  Receive  Ready/ Receive  not  Ready 

REFERENCES:  FRMR  -  frame  reject  state  variable 

MODIFIES:  REMOTE  BUSY  -  state  variable 

CALLS:  CHKPNT 

EXIT:  RCV 

FRMRI 

FUNCTION  After  the  frame  has  been  validated  the  CHKPNT 

routine  is  called  to  update  the  acknowledgement 
of  frames  through  N(R)-1.  If  not  in  frame 
reject  state  the  REMOTE  BUSY  state  variable  is 
cleared  or  set  depending  on  whether  a  receive 
ready  (RR)  or  receive  not  ready  (RNR)  was 
received . 
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SREJ  Module 


Receive  SREJECT  routine 


REFERENCES : 


MODIFIES : 


CALLS : 


EXIT: 


FUNCTION: 


N(R)  received 
P/F  received 

FRMR  -  frame  reject  state  variable 
REJ/SREJ  ACTIONED  state  variable 
CHECKPOINT  RETRANS.  state  variable 
P/F  (old)  value  set  when  SREJ  actioned 
N(R)  (old) 

Ss  -  specific  send  variable 
REJ/SREJ  ACTIONED  State  variable 
REMOTE  BUSY  state  variable 

CHKPNT 

RCV 

FRMRI 

The  SREJ  function  is  similar  to  the  REJ  function. 
After  the  frame  has  been  validated,  a  test  is 
made  to  determine  if  REJ  or  SREJ  are  currently 
being  actioned.  If  REJ  is  being  actioned, 
operation  is  identical  to  that  of  the  REJ 
subroutine  (no  error  recovery  is  performed) . 

If  SREJ  is  being  actioned,  the  P/F  and  N(R) 
of  the  original  are  compared  to  the  P/F  and 
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N ( R)  of  the  current  SREJ.  If  the  original 
P/F  is  equal  to  zero  for  a  secondary  or  primary/ 
combined  station,  the  next  SREJ  is  not  actioned 
if  the  P/F  =1  and  N(R)  has  the  same  value  and 
numbering  cycle  as  the  first  SREJ.  If  no  REJ/SREJ 
is  being  actioned  and  no  checkpoint  retransmission 
is  in  progress  a  reject  exception  condition  is 
established.  The  P/F  bit  and  N(R)  are  recorded 
for  possible  later  use  as  discussed  above. 

The  single  frame  to  be  retransmitted  is  made  known 
to  the  transmit  subroutine  and  the  CHKPNT  routine 
is  called  to  update  the  acknowledgement  of  frames 
through  N (R) -1 . 
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REJ  Module 


Receive  REJECT  routine 


REFERENCES:  N (R)  received 

P/F  received 

FRMR  -  frame  reject  state  variable 
REJ/SREJ  ACTIONED  state  variable 
CHECKPOINT  RETRANS.  state  variable 

MODIFIES:  S  -  send  variable 

TPAK- variables  and  status  bits 
REJ/SREJ  ACTIONED  state  variable 
REMOTE  BUSY  state  variable 

CALLS :  CHKPNT 

EXIT:  RCV 

FRMRI 

FUNCTION:  After  the  REJ  frame  has  been  validated  (no 

FCS  error  and  not  in  FRMR  state)  a  test  is  made 

to  determine  if  a  REJECT  or  SREJECT  command/ 
response  is  currently  being  actioned.  If  not, 
and  if  the  frame  indicated  in  the  N(R)  is 
not  being  retransmitted  due  to  the  checkpointing 
mechanism,  a  reject  exception  condition  is 
established.  The  send  variable,  S,  is  made  equal 
to  the  N (R)  received  and  the  pointers  in  the 
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transmit  buffer  are  adjusted  accordingly.  The 
CHKPNT  routine  is  called  to  update  the  acknowl¬ 
edgement  of  frame  through  N(R)-1. 


CHKPNT  Subroutine 


Checkpoint  recovery  routine 


REFERENCES : 


MODIFIES: 


EXIT: 


FUNCTION: 


N (R)  received 
P/F  received 

FRMR  -  frame  reject  state  variable 
Information  transfer  state  variable 
REJ/SREJ  ACTIONED  -  state  variable 

S  -  send  variable 

TPACK  variables  add  status  bits 

REJ/SREJ  ACTIONED  state  variable 

NORMAL  RETURN 

FRMREJ 

FRMRl 

The  N(R)  received  is  check  for  validity.  An 
invalid  N(R)  is  defined  as  a  number  that  points 
to  an  I-frame  that  has  been  transmitted  previously 
and  acknowledged,  or  to  an  I-frame  that  has  not 
been  transmitted  and  is  not  the  next  sequential 
I-frame  pending  transmission.  If  the  N(R)  is 
invalid,  FRMREJ  is  called.  Otherise  the  acknowl¬ 
edgement  of  frames  through  N(R)-1  is  updated 
via  the  adjustment  of  pointers  and  variables  in 
TPACK.  If  the  poll  (or  final)  bit  is  set,  a 
check  is  made  to  determine  if  N(R)-1  points  to 
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the  frame  transmitted  previously  with  the 
final  (or  poll)  bit  set.  If  not,  the  send 
variable  (S)  is  reset  to  the  earliest  out¬ 
standing  frame  preceding  the  frame  with  the 
final  (poll)  bit  set,  as  long  as  this  frame 
is  not  being  transmitted  due  to  REJ  or  SREJ. 
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RCNTRL  Subroutine  -  Unpacks  control  field 


REFERENCES: 


MODIFIES : 


EXIT: 


FUNCTION: 


CNTFLD  -  input  control  field 
COMTAB  -  command  fable 
VALTAB  -  command  validity  table 
FRTAB  -  frame  type  table 
STATE  -  station  type  and  mode 

POLLP  -  provisional  pcll/'final  bit 
NRP  -  provisional  N(R) 

NSP  -  provisional  N(S) 

FTYPE  -  frame  type 

NORMAL  RETURN 

A  provisional  P/F  bit  is  extracted  from  the 
control  field.  Next,  the  frame  type  is  determined 
by  matching  the  masked  control  field  against 
a  table  of  implemented  commands  and  responses 
The  I  frame  is  expected  first,  followed  by 
the  supervisory  and  the  unnumbered  frames.  If 
no  table  entry  matches  the  frame  type,  the 
command/tesponse  is  marked  invalid.  Otherwise 
the  frame  type  is  checked  against  current  station 
type  and  mode.  If  valid,  the  provisional  N(R) 
and  N (S)  are  extracted  and  the  frame  type  is 
returned . 
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4.3  DETAILED  FLOW  CHARTS 


k 


The  detailed  flow  charts  are  shown  in  Figures  4-6 
through  4-26.  Note  that  Figure  4-13,  Receive  I  Subroutine, 
contains  three  optional  recovery  routines  depending  on  the 
method  to  be  used  for  error  recovery.  The  three  routines 
provide  for  a  pure  REJECT  recovery,  or  a  pure  SREJECT 
recovery,  or  neither  of  these  two  (checkpoint  recovery  by 
default) . 
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Figure  4-13  continued 
Optional  REJECT  RECOVERY  Module 
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Figure  4- 17  Checkpoint  Subroutine 
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Figure  4-19  Transmit  FRMR  Process 


I  S ET 


‘State-  -XT’s 
N£N\ 

C  ,  ab^a) 


ixcru/PTe 

Te.AfJSMi'T' 

-tas^ 

Cm-yA) 


ACTl  s/ATE 
SENj-DT 


l 


Tfc--Df^\ 


J 


(TO.-UA) 


IF  ABM 
S«T  ASCfESS 

nro 


\£  ABM  ££T  4jSS& 
“TO  S«sCjO*J-EAii'/ 


^CjBVT  Tu(2-kJ  Okj  “TfrVjSM  iTTSR- 

i  -t  1>M  CC(^  uA.) 

Tin  (UA')  | 


IP  NJfS-iA 

•^rAcr 

tihfcxtt 


TU(t*J  CrPF- 

P>*J  D  Te^LM 
PrCoce.S3 


r  EWD  ^ 
vfi^<L£SS  y 


Figure  4-22  Transmit  DM  Process 
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Transmit  Data  Byte  Macro 
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Figure  4-25  WAIT  &  SIGNAL  Processes 
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5.0  MICROPROCESSOR  CODING  AND  TESTING 

An  example  of  the  6800  microprocessor  code  is  shown 
in  Figure  5-1.  This  figure  shows  the  assembly  language 
instructions  and  assembled  code  for  the  RCNTRL  subroutine. 

The  description  of  this  subroutine  was  given  in  Section  4. 

This  subroutine  requires  94  bytes  for  instructions  plus  39 
bytes  for  tables  for  a  total  of  133  bytes  in  ROM.  Testing 
of  the  6800  code  was  accomplished  on  a  6800-based1  micro¬ 
computer.  An  exhaustive  test  was  made  of  all  256  possibilities 
of  the  input  control  field.  The  resulting  frame  type,  P/F 
bit,  N(R),  and  N(S)  extracted  was  examined  for  correctness 
and  validity  as  compared  to  the  frame  valid  table. 
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***  kCNTKL  SUbkOtJT  INI: 


Fiyure  5-1  RCNTRL  Code 


129  0083  A8  I  l.B  lOlOiOOOK  V  KHtv 

130  0084  08  M  B  000010008  RblT 

131  0081*  B8  M  B  10]  1100Gb  b.'.KM 

132  00 Jc,  08  M  B  00001 GOOb  80HM 


6 . 0  DISCUSSION  OF  FEASIBILITY 


As  discussed  previously,  one  of  the  objectives  of 
this  program  is  to  determine  the  practicality  of  using  a 
microprocessor,  such  as  the  M6800,  to  implement  the  un¬ 
balanced  normal,  unbalanced  asynchronous,  and  balanced 
asynchronous  class  of  procedures.  Two  major  factors 
affecting  the  feasibility  are  the  number  of  instructions 
required  to  implement  the  protocol,  and  the  time  necessary 
to  execute  these  instructions.  The  total  number  of  instructions 
has  a  significant  effect  on  the  cost  of  developing  a  proces¬ 
sor-based  system,  and  the  throughput  (or  baud-rate  over 
the  communication  line  in  this  instance)  is  determined  by 
the  execution  speed  through  critical  paths  on  the  program. 

These  factors  are  disucssed  below. 

6.1  MEMORY  REQUIREMENTS 

The  number  of  instructions  required  to  implement  the 
protocol  including  REJ  or  SREJ  can  be  estimated  by  examining 
the  detailed  flow  charts  in  Section  4.  The  protocol  includ¬ 
ing  pure  SREJ  is  estimated  to  require  1300  instructions; 
this  represents  an  increase  of  450  instructions  over  the 
protocol  without  SREJ.  The  pure  REJ  protocol  is  estimated 
at  100  instructions  less  or  1200  instructions.  Approximately 
250  instructions  will  be  required  for  the  operating  system, 
depending  on  desired  features.  RAM  is  required  for  variable 
storage  and  data  buffers. 

6 . 2  EXECUTION  TIME 

The  speed  at  which  the  microprocessor  can  execute  the 

protocol  in  real-time  depends  to  a  large  extent  on  the  actual 
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hardware/sof tware  design:  The  hardware  design  can  be 
"standard"  or  it  can  include  many  processes  accomplished  in 
hardware  (such  as  the  F6856) .  For  the  purpose  of  this  pro¬ 
gram,  the  standard  approach  with  the  aid  of  the  F6856  is 
assumed.  The  software  design  must  address  the  time-critical 
portions  of  the  simultaneous  transmit/receive  processes 
to  ensure  that  these  critical  processes  may  be  serviced 
in  real  time.  For  this  program,  no  attempt  has  been  made 
to  optimise  these  processes,  since  a  thorough  analysis  is 
required  to  determine  just  what  is  "critical".  However, 
some  rough  estimates  can  be  made  based  on  the  current  state 
of  the  design. 

Assuming  a  MPU  rate  of  1  cycle/microsec.  it  appears 
that  a  9.6  or  19.2  kilobit/sec.  transmission  rate  would  not 
be  too  difficult.  That  is,  a  19.2  kilobit/sec.  rate  is 
equivalent  to  400  microseconds  per  byte  transmitted,  which 
is  approximately  100  instructions.  It  should  be  possible 
to  implement  the  critical  parts  of  the  send/receive  process 
using  between  100  and  200  instructions.  A  more  thorough 
analysis  might  reveal  that  100  kilobit/sec  rate  may  be 
possible,  but  certainly  difficult.  A  faster  MPU  and 
additional  hardware  might  be  required.  Another  tradeoff 
that  can  be  made  is  memory  for  speed;  that  is,  table  look¬ 
up  may  be  used  in  some  cases  to  reduce  the  number  of 
instructions  required  to  be  executed. 
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APPENDIX  A 
OPERATING  SYSTEM 


The  design  of  the  operating  system  (OS)  is  important 
because  it  can  have  a  significant  impact  on  the  time  required 
to  switch  the  processor  among  concurrent  processes  and  to 
handle  interrupts.  The  approach  taken  makes  use  of  the 
"standard"  WAIT  and  SIGNAL  primitives  together  with  event 
variables.  No  attempt  has  been  made  to  design  a  complete 
operating  system;  only  those  routines  required  to  handle 
the  concurrent  processes  are  included. 

Each  software  process  is  defined  to  be  in  one  of 
three  states; 

ACTIVE  (RUNNING)  STATE  -  Executing  computer  instructions 

BLOCKED  STATE  -  Waiting  for  the  occurrence  of  an  event 
in  another  process 

READY  STATE  -  Waiting  for  processor  to  run 
State  Tranisitons  are  illustrated  in  the  state  diagram  of 
Figure  A-l 


Figure  A-l  Process  State  Diagram 


Processes  may  be  created  or  terminated  by  other  processes, 
and  each  process  is  defined  to  be  either  running  or  on  the 
blocked  queue  or  the  ready  queue  depending  on  its  state. 
Associated  with  each  process  is  a  process  control  block 
( PCB )  which  contains  an  area  to  save  the  CPU's  registers 
when  the  process  is  interrupted,  a  pointer  to  the  next 
PCB  in  the  queue,  and  the  process'  priority. 

If  the  process  currently  running  become  blocked,  it 
is  changed  from  the  ACTIVE  state  to  the  BLOCKED  state  via 
the  WAIT  routine.  For  example,  if  the  receive  process  is 
executing  instructions  and  wishes  to  obtain  a  byte  of  data 
from  the  LSI  interface  chip  buffer,  the  process  tests  the 
event  variable  RDAFLG  to  determine  whether  or  not  the  byte 
of  data  is  available.  If  available,  the  process  continues; 
if  not,  the  WAIT  routine  is  called  to  save  the  receive  process 
registers,  insert  the  receive  process  into  the  blocked  queue, 
and  get  a  new  process  from  the  ready  queue,  restore  the 
registers  of  the  new  process,  and  run  the  new  process.  The 
receive  process  continues  where  it  left  off  after  an  interrupt 
from  the  LSI  chip  signals  that  a  byte  of  data  is  available, 
the  interrupt  service  routine  services  the  interrupts, 
and  the  receive  process  is  moved  to  the  running  state  via 
the  SIGNAL  routine.  The  SIGNAL  routine  removes  the 
receive  process  from  the  blocked  queue  and  restores  it  to 
the  running  state.  Any  process  is  blocked  and  restored  in 
this  way  by  the  WAIT  and  SIGNAL  routines  respectively,  and 
by  the  appropriate  interrupt  service  routine. 

The  6800  has  but  one  interrupt  input  that  is  maskable. 


This  means  that  unless  some  additional  hardware  is  used,  all 


interrupt  lines  must  be  logically  ORed  and  fed  to  the  CPU 
via  the  single  interrupt:  input,  IRQ .  This  requires  that  the 
interrupt  service  routine  poll  the  various  devices  that 
might  cause  an  interrupt  to  determine  what  device  actually 
did  cause  the  interrupt.  The  order  in  which  the  devices 
are  polled  determines  the  interrupt  priority.  The  following 
five  events  cause  interrupts  from  the  6856  protocol  chip: 

RDA  -  Received  data  available 

ROVR  -  Receiver  overrun  (data  was  not  read  from  buffer 
before  new  byte  was  loaded) 

TOR  -  Transmitter  overrun 

TBMT  -  Transmitter  buffer  empty 

TUR  -  Transmitter  underrun  (data  was  not  loaded  in 
transmitter  buffer  in  time  to  transmit) 

In  addition,  two  timers  are  assumed  to  be  part  of  the  design, 
one  to  provide  a  time  slicing  function  to  interrupt  a  running 
process  periodically  to  give  the  CPU  to  a  different  process, 
and  a  time-out  timer  to  indicate  an  overdue  response.  These 
two  functions  may  be  provided  by  one  timer  and  appropriate 
software  or  by  two  separate  timers. 
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